1. Field of the Invention
The present invention relates to systems and methods for digitally signing data, and in particular to a system and method for enforcing restrictions regarding the digital signing and use of code images.
2. Description of the Related Art
Data signing is a process of digitally signing data to confirm that the author of the data is who it purports to be and to guarantee that the data has not been altered or corrupted since it was signed by use of a cryptographic hash. Data signing is particularly useful in cases wherein the data comprises software code, such as executables and scripts, as corrupted or hacked software code is particularly pernicious.
FIG. 1 is a diagram illustrating the code signing and verification process. In order to sign the code, the software publisher needs to generate a private key 106A-public key 106B pair and submit the public key 106B to a certificate authority (CA) along with a request to issue a code signing certificate. The CA verifies the identity of the publisher and authenticates the publisher's digitally signed certificate request. If this vetting and key verification process is successful, the CA bundles the identity of the publisher with the public key 106B and signs the bundle, creating the code signing certificate 112.
Armed with the code signing certificate 112, the publisher is ready to sign the code. When the code is signed, the original file is added to several pieces of information. This bundled information is used by the recipient's user agent to authenticate the publisher and check for code-tampering.
A hash of the data 110 (hereinafter alternatively referred to as code) is produced, using a hashing module 102. The hashed code is a cryptographically unique representation of the code, and is only reproducible by the recipient of the code using unaltered code and the same hashing algorithm that was used to create the hash. This hash is later signed using the publisher's private key 106A, as described below. The reason the hash instead of the code is signed is that public-key algorithms are inefficient for signing large objects, and the hashing algorithm creates a fixed-length digest of the code that is much smaller in side.
Next, the hashed code is digitally signed using the publisher's private key 104A, by the signing module 104A. This can be accomplished by passing the hash through a signing algorithm implemented by the signing module 104A using the publisher's private key 106A as an input. Information about the publisher and the CA may be drawn from the code signing certificate 112 and incorporated into the signature. Next, the original code 110, signature, and code signing certificate are bundled together. The code signing certificate 112 is added to the bundle (as the public key it contains is required to authenticate the code when it is verified).
The signature is verified as also shown in FIG. 1. First, the original code is passed through the same hashing module 102 implementing the same hashing algorithm described above to create hashed code. The public key 106B of the publisher is extracted from the bundle and applied to the signed hash 106 information, and applied to the signed hash 106 by signature module 104B, thus applying the public key 106B to reveal the hash that was calculated as described above when the file was signed. The two hashes (hashed data 1 and hashed data 2) are compared; if equal, then the code has not changed and the signature is considered valid. Next, the code signing certificate 112 is checked to make sure that it was signed by a trusted CA, and the expiry date of the code signing certificate 112 is checked. The code signing certificate may also be checked against the revocation lists to be sure that it is valid. If the code signing certificate 112 was signed by a trusted CA and has not been revoked, the data or code 110 is considered valid, it is accepted for use by the user device. If the file is not considered valid or if the CA is not a trusted CA, the user device may provide the option of accepting and executing the code from an unknown publisher or rejecting the code.
Some code signing formats are accepted by many different device models. For instance, code signing compatible with the Data Over Cable Services Interface Specification (DOCSIS) is utilized in a number of different consumer premises equipment (CPE) devices which may include an embedded cable modem and other functionality such as a set-top-box (STB), integrated receiver/decoder (IRD) used to receive media programs or a Voice Over Internet Protocol (VoIP) gateway. For all types of devices that include a DOCSIS cable modem, a secure code download may be signed using the DOCSIS format. Furthermore, each company or software publisher is generally issued one Code Verification Certificate (CVC) by a CA such as CABLE LABS for the purpose of DOCSIS code signing. Therefore, a single signing key is utilized in that case to sign code destined for many different device models.
However, it is sometimes undesirable for a particular employee of the publisher to have the ability to sign code downloads for many device models. This may be a concern for employees within the company or publisher that makes the corresponding devices and is even more of a concern for employees of a cable operator publishing new code which also desires to build and then sign code images using the same DOCSIS code signing format using a signing key which belongs to the device manufacturer.
What is needed is a system and method which restricts the ability to sign code based upon the status of a particular employee and/or the devices for which the code is intended to be installed. Described below is a solution based on a code signing server which has different configurations assigned to employees which can sign code for any device vs. employees usually of other companies) that are restricted go signing code only for specific configurations corresponding to specific device models.